Method and system for using stored data items in native data formats in emulated e-mode programs

ABSTRACT

An embodiment of the invention is a technique for enabling an emulator that emulates an e-mode program to utilize stored data items whose values are stored in native data format in native memory. The emulator fetches an item referenced by the e-mode program. The referenced item comprises a tag field and a data field. The emulator determines whether the tag field of the referenced item indicates that the referenced item is an external reference word (ERW). If the tag field of the referenced item indicates that the referenced item is an ERW, the emulator decodes the ERW to obtain a data type and a pointer. The pointer corresponds to a location of a stored data item in native memory.

BACKGROUND

1. Field of the Invention

Embodiments of the invention relates generally to methods and systemsfor emulating e-mode programs on a server having a differentarchitecture and operating system platform.

2. Description of Related Art

The stack architecture of the ClearPath/NX server product line of UnisysCorporation supports the ALGOL programming language and its extensions.Their implementations are based on a specification known as e-mode. Inorder to run e-mode programs on a native server having a differentarchitecture and operating system platform, such as an Intelprocessor-based architecture with a Microsoft Windows operating systemplatform, one approach is to emulate all the e-mode programs. Since allthe e-mode programs are emulated, all the data items that are used bythe e-mode programs are stored in e-mode data format. This approach doesnot take full advantage of the speed and characteristics of the nativeserver on which the emulator is running. As a result, performance of theemulator is sub-optimal with this approach.

Another approach is to translate most critical e-mode programs toprograms such as C++ programs that can be compiled to run efficiently onthe native server, and to emulate only the remaining non-translatede-mode programs. If each data item that is used by both the compiled C++programs and the emulated e-mode programs has to be stored in bothnative data format and e-mode format, then, in addition to causingoverhead in memory storage, this will cause too much of overhead inkeeping the two copies of each common data item in synchronization. If acommon data item is kept only in e-mode format, there will be overheadin reformatting the data item to native data format each time a compiledC++ program needs to use the data item. The overall performance would beimproved if all the data items that are used by the compiled C++programs are stored in native data format. However, in this case, theemulator must be able to use common data items that are stored in nativedata format for the emulated e-mode programs. This is not possible withcurrent emulators that cannot utilize the data items that are stored innative data format for the emulated e-mode programs. Thus, there is aneed for a technique that enables an emulator to utilize the data itemsthat are stored in native data format for the emulated e-mode programs.

SUMMARY OF THE INVENTION

An embodiment of the invention is a technique for enabling an emulatorthat emulates an e-mode program to utilize stored data items whosevalues are stored in native data format in native memory. The emulatorfetches an item referenced by the e-mode program. The referenced itemcomprises a tag field and a data field. The emulator determines whetherthe tag field of the referenced item indicates that the referenced itemis an external reference word (ERW). If the tag field of the referenceditem indicates that the referenced item is an ERW, the emulator decodesthe ERW to obtain a data type and a pointer. The pointer corresponds toa location of a stored data item in native memory.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may best be understood by referring to the followingdescription and accompanying drawings that are used to illustrateembodiments of the invention. In the drawings:

FIG. 1 is a block diagram illustrating a new system 100 in which theemulator of the present invention may be used to improve the overallperformance.

FIG. 2 illustrates the current (prior art) e-mode format of a data item.

FIG. 3A illustrates the new e-mode format of a data item.

FIG. 3B illustrates an example of an ERW for a data item in an array innative memory.

FIG. 4 is a flowchart illustrating the process 400 of the presentinvention.

FIG. 5 is a flowchart illustrating an embodiment 500 of block 408 ofFIG. 4, when the specific emulator operator being in use is a ValueCall(VALC) operator.

FIG. 6 is a flowchart illustrating an embodiment 600 of block 408 ofFIG. 4, for a StoreDelete (STOD) operator of the emulator.

FIG. 7 is a flowchart illustrating an embodiment 700 of block 412 ofFIG. 4, for a ValueCall (VALC) operator of the emulator.

FIG. 8 is a flowchart illustrating an embodiment 800 of block 412 ofFIG. 4, for a StoreDelete (STOD) operator of the emulator.

FIG. 9 is a diagram illustrating a server/client system 900 in which oneembodiment of the invention can be practiced.

DESCRIPTION

An embodiment of the invention is a technique for enabling an emulatorthat emulates an e-mode program to utilize stored data items whosevalues are stored in native data format in native memory. The emulatorfetches an item referenced by the e-mode program. The referenced itemcomprises a tag field and a data field. The emulator determines whetherthe tag field of the referenced item indicates that the referenced itemis an external reference word (ERW). If the tag field of the referenceditem indicates that the referenced item is an ERW, the emulator decodesthe ERW to obtain a data type and a pointer. The pointer corresponds toa location of a stored data item in native memory.

The technique of the present invention can significantly enhance theperformance of the emulator in which the technique is implemented. Thespecific implementation employed may vary depending on the definitionsof the different ERWs and their specific representations.

In the following description, numerous specific details are set forth.However, it is understood that embodiments of the invention may bepracticed without these specific details. In other instances, well-knowncircuits, structures, and techniques have not been shown in order not toobscure the understanding of this description.

One embodiment of the invention may be described as a process which isusually depicted as a flowchart, a flow diagram, a structure diagram, ora block diagram. Although a flowchart may describe the operations as asequential process, many of the operations can be performed in parallelor concurrently. In addition, the order of the operations may bere-arranged. A process is terminated when its operations are completed.A process may correspond to a method, a program, a procedure, etc.

The stack architecture of the ClearPath/NX server product line of UnisysCorporation supports the ALGOL programming language and its extensions.Their implementations are based on a specification known as e-mode. Inorder to run e-mode programs on a native server having a differentarchitecture and operating system platform, such as an Intelprocessor-based architecture with a Microsoft Windows operating systemplatform, one approach is to emulate all the e-mode programs. Since allthe e-mode programs are emulated, all the data items that are used bythe e-mode programs are stored in e-mode data format. This approach doesnot take full advantage of the speed and characteristics of the nativeserver on which the emulator is running. As a result, performance of theemulator is sub-optimal with this approach.

A new approach is to translate most critical e-mode programs to programssuch as C++ programs that can be compiled into Dynamic Link Libraries(DLLs) to run efficiently on the native server, and to emulate only theremaining non-translated e-mode programs. Since the non-translatede-mode programs are usually not critical, the overall performance ofthis approach (measured as speed of the execution and emulation of theprograms) depends mostly on the performance of the DLLs. Therefore, theoverall performance will be improved if all the data items that are usedby the compiled C++ programs are stored in native data format. Themethod of the present invention enables the emulator to utilize the dataitems that are stored in native data format for the emulated e-modeprograms.

FIG. 1 is a block diagram illustrating a new system 100 in which theemulator of the present invention may be used to improve the overallperformance.

All e-mode programs can be translated to C++ programs. E-mode programsthat cannot be translated via automated translation can be manuallytranslated at a higher cost. Critical e-mode programs are usuallyselected to be translated.

The selected e-mode programs 102 are translated into C++ programs 104which are then compiled into Dynamic Link Libraries (DLLs) for a nativeserver platform (such as Intel processor/Windows operating system). Whena selected e-mode program 102 is run, the emulator 108 executes thecorresponding DLL rather than emulating the original e-mode program 102,producing identical results in significantly less time. Data items 110used or generated by the DLLs are stored in native data format in nativememory.

The non-translated e-mode programs 112 are emulated on the fly by theemulator 108. The emulator 108 of the present invention is capable ofusing the stored data items in native data format 110 as input for theemulated e-mode programs 112. The emulator 108 is also capable ofconverting a data item generated by the emulated e-mode program tonative data format and storing it in the native memory at a specifiedaddress. Data items that are used only by the emulated e-mode programs112 and not by the DLLs 106 are stored in e-mode memory 114. E-modememory 114 may include a stack or an array in memory.

FIG. 2 illustrates the current (prior art) e-mode format of a data item.Each data item word in e-mode format includes a data field of 48-bits(bit 0 through bit 47) and a tag field of 4 bits (bit 48 through bit51). The values 0 through 15 of the tag field are used by the e-modeoperators to determine the data type of the data item. For example, atag value of 0 indicates that the content of the 48-bit data field is asingle precision real number. A double precision number is composed oftwo data item words, each with a tag value of 2. A descriptor whichdefines an area of memory has a tag value of 12.

In accordance with the method of present invention, the tag field of adata item in e-mode format is extended to more than 4 bits, so that aspecific tag value above 15 can be used to indicate that thecorresponding data item is an external reference word (ERW) of aparticular type. In one embodiment, the tag field is 8 bits long. ERW isa new type of e-mode data item introduced by the present invention inorder to find and access a data item stored in native data format innative memory. The remaining 48 bits of the ERW contains informationabout the location of a data item stored in native memory, which can bedecoded by the emulator to locate the stored data item. For example, atag value of 16 may be used to indicate that the ERW is for a singleprecision number; the remaining 48 bits of the ERW contains a pointer tothe location of this single precision number in native memory. A tagvalue of 18 may be used to indicate that the ERW is for a doubleprecision number; the remaining 48 bits of the ERW contains a pointer tothe location of this double precision number in native memory. Notethat, since a double precision number is stored in two consecutivelocations in memory, only the address of the first location is needed tolocate this number.

In accordance with the present invention, the operators in the emulatorare modified to be able to accept ERWs as inputs. For example: one ofe-mode architecture's most common operators is VALC (value call) whichfetches a data item and places the data item on top of a stack. In theprior art, the first reference to the data item is encoded within theoperator stream. This reference may point to the data item itself, or toan indirect reference word (a SIRW). This SIRW may then point to thedata item or another SIRW, and so on. The VALC operator follows areference chain for as long as it goes.

In the present invention, the VALC operator is modified to recognize anERW from the tag field of the ERW so that the VALC operator can thenfetch the data item directly from native memory as directed by theremainder of the ERW and convert it to e-mode format. Similarly, theStoreDelete (STOD) operator is modified to recognize an ERW on the stackso that the STOD operator can then convert the data to be stored tonative format and use the location information in the ERW to store theconverted data.

Referring to FIG. 1, when a DLL 106 needs to call an external procedure,the emulator 108 determines whether the external procedure is anotherDLL or an e-mode program 112. At the point in time where the emulatordetermines that the external procedure that is going to be called by theDLL with stored data items as parameters is an e-mode program, theemulator constructs the ERWs corresponding to the stored data items andputs the ERWs on the stack to pass the ERWs as parameters to the e-modeprogram.

FIG. 3A illustrates the new e-mode format of a data item. The tag fieldis more than 4 bits long. The data field is 48-bit long.

FIG. 3B illustrates an example of an ERW for a data item in an array innative memory. The tag value is 17. The first 32 bits of the data fieldprovide the address of the array, which is a pointer to the base of thearray. The remaining 16 bits of the data field provide an index to thearray, which points to a specific element in the array.

FIG. 4 is a flowchart illustrating the process 400 of the presentinvention. This process is used by various operators of the emulator 108that emulates an e-mode program 112 (FIG. 1) to utilize stored dataitems whose values are stored in native data format in native memory.

Upon Start, process 400 fetches an item referenced by the e-modeprogram, the referenced item comprising a tag field and a data field(block 402). Process 400 determines whether the tag field of thereferenced item indicates that the referenced item is an externalreference word (ERW) (block 404). If the tag field of the referenceditem indicates that the referenced item is an ERW, process 400 decodesthe ERW to obtain a data type and a pointer, the pointer correspondingto a location of a stored data item in native memory (block 406).Process 400 then proceeds in accordance with the function of thespecific emulator operator being in use, using the data item in nativedata format (block 408) then process 400 is terminated. If the tag fieldof the referenced item does not indicate that the referenced item is anERW, process 400 determines whether the tag field indicates that thereferenced item is an indirect reference word (SIRW) (block 410). Notethat SIRW is a known type of data item in prior art e-mode format. ASIRW may point to another SIRW or to the final data item. If the tagfield indicates an indirect reference word, process 400 fetches the itemthat is referenced by the indirect reference word (block 402) andcontinues to block 404 as described above. If the tag field does notindicate an indirect reference word (meaning the data field of thereferenced item contains the data item itself in e-mode data format),process 400 proceeds in accordance with the function of the specificemulator operator being in use, using the data item in e-mode dataformat (block 412), then process 400 is terminated.

FIG. 5 is a flowchart illustrating an embodiment 500 of block 408 ofFIG. 4, when the specific emulator operator being in use is a ValueCall(VALC) operator. Upon Start, process 500 creates an object reference innative format in accordance with the data type and pointer that havebeen obtained from decoding the ERW (block 502). Note that, although thepointer obtained from decoding the ERW provides the location of the dataitem in the native memory, it is not in native format that can be useddirectly to access that location. Process 500 fetches the value of thestored data item from the native memory using the newly created objectreference (block 504). Process 500 reformats the fetched data item valueto e-mode data format (block 506). Process 500 places the reformatteddata item value on top of a stack to provide the reformatted value tothe e-mode program (block 508), then is terminated.

FIG. 6 is a flowchart illustrating an embodiment 600 of block 408 ofFIG. 4, for a StoreDelete (STOD) operator of the emulator. Upon Start,process 600 creates an object reference in native format in accordancewith the data type and pointer that have been obtained from decoding theERW (block 602). The obtained data type indicates the data type of thedata item to be stored. The obtained pointer provides the informationabout the location in native memory where the data item is to be stored,but is not in native format that can be used directly to access thatlocation. Process 600 reformats to native data format the value of thedata item to be stored (block 604). Process 600 stores the reformatteddata item value in native memory using the created object reference(block 606), then process 700 is terminated.

FIG. 7 is a flowchart illustrating an embodiment 700 of block 412 ofFIG. 4, for a ValueCall (VALC) operator of the emulator. Upon Start,process 700 places the referenced item that is in e-mode data format ontop of a stack (block 702), then process 700 is terminated.

FIG. 8 is a flowchart illustrating an embodiment 800 of block 412 ofFIG. 4, for a StoreDelete (STOD) operator of the emulator. Upon Start,process 800 places the referenced item that is in e-mode data format ine-mode memory (block 802), then process 800 is terminated.

FIG. 9 is a diagram illustrating a server/client system 900 in which oneembodiment of the invention can be practiced. The server/client system900 includes a processor 910, a processor bus 920, a memory control hub(MCH) 930, a system memory 940, an input/output control hub (ICH) 950, aperipheral bus 960, a mass storage device 970, and input/output devices980 ₁ to 980 _(K). Note that the server/client system 900 may includemore or less elements than these elements.

The processor 910 represents a central processing unit of any type ofarchitecture, such as embedded processors, mobile processors,micro-controllers, digital signal processors, superscalar computers,vector processors, single instruction multiple data (SIMD) computers,complex instruction set computers (CISC), reduced instruction setcomputers (RISC), very long instruction word (VLIW), or hybridarchitecture.

The processor bus 920 provides interface signals to allow the processor910 to communicate with other processors or devices, e.g., the MCH 930.The host bus 920 may support a uniprocessor or multiprocessorconfiguration. The host bus 920 may be parallel, sequential, pipelined,asynchronous, synchronous, or any combination thereof.

The MCH 930 provides control and configuration of memory andinput/output devices such as the system memory 940, the ICH 950. The MCH930 may be integrated into a chipset that integrates multiplefunctionalities such as the isolated execution mode, host-to-peripheralbus interface, memory control. The MCH 930 interfaces with theperipheral bus 960. For clarity, not all the peripheral buses are shown.

The system memory 940 stores system code and data. The subsystem memory940 is typically implemented with dynamic random access memory (DRAM) orstatic random access memory (SRAM). The system memory 940 may includeprogram code or code segments implementing one embodiment of theinvention. The system memory 940 includes an emulator 942 and e-modememory 944. Any one of the elements of the emulator 942 may beimplemented by hardware, software, firmware, microcode, or anycombination thereof. The system memory 940 may also include otherprograms or data that are not shown, such as an operating system. Theemulator 942 contains program code that, when executed by the processor910, causes the processor 910 to perform operations as described herein.The emulator 942 also includes native memory 943.

The ICH 950 has a number of functionalities that are designed to supportI/O functions. The ICH 950 may also be integrated into a chipsettogether or separate from the MCH 930 to perform I/O functions. The ICH950 may include a number of interface and I/O functions such as PCI businterface to interface with the peripheral bus 960, processor interface,interrupt controller, direct memory access (DMA) controller, powermanagement logic, timer, system management bus (SMBus), universal serialbus (USB) interface, mass storage interface, low pin count (LPC)interface, etc.

The mass storage device 970 stores archive information such as code,programs, files, data, applications, and operating systems. The massstorage device 970 may include compact disk (CD) ROM 972, a digitalvideo/versatile disc (DVD) 973, floppy drive 974, hard drive 976, flashmemory 978, and any other magnetic or optic storage devices. The massstorage device 970 provides a mechanism to read machine-accessiblemedia. The machine-accessible media may contain computer readableprogram code to perform tasks as described herein.

The I/O devices 980 ₁ to 980 _(K) may include any I/O devices to performI/O functions. Examples of I/O devices 980 ₁ to 980 _(K) includecontroller for input devices (e.g., keyboard, mouse, trackball, pointingdevice), media card (e.g., audio, video, graphics), network card, andany other peripheral controllers.

Elements of one embodiment of the invention may be implemented byhardware, firmware, software or any combination thereof. The termhardware generally refers to an element having a physical structure suchas electronic, electromagnetic, optical, electro-optical, mechanical,electromechanical parts, etc. The term software generally refers to alogical structure, a method, a procedure, a program, a routine, aprocess, an algorithm, a formula, a function, an expression, etc. Theterm firmware generally refers to a logical structure, a method, aprocedure, a program, a routine, a process, an algorithm, a formula, afunction, an expression, etc that is implemented or embodied in ahardware structure (e.g., flash memory, ROM, EROM). Examples of firmwaremay include microcode, writable control store, micro-programmedstructure. When implemented in software or firmware, the elements of anembodiment of the present invention are essentially the code segments toperform the necessary tasks. The software/firmware may include theactual code to carry out the operations described in one embodiment ofthe invention, or code that emulates or simulates the operations. Theprogram or code segments can be stored in a processor or machineaccessible medium or transmitted by a computer data signal embodied in acarrier wave, or a signal modulated by a carrier, over a transmissionmedium. The “processor readable or accessible medium” or “machinereadable or accessible medium” may include any medium that can store,transmit, or transfer information. Examples of the processor readable ormachine accessible medium include an electronic circuit, a semiconductormemory device, a read only memory (ROM), a flash memory, an erasable ROM(EROM), a floppy diskette, a compact disk (CD) ROM, an optical disk, ahard disk, a fiber optic medium, a radio frequency (RF) link, etc. Thecomputer data signal may include any signal that can propagate over atransmission medium such as electronic network channels, optical fibers,air, electromagnetic, RF links, etc. The code segments may be downloadedvia computer networks such as the Internet, Intranet, etc. The machineaccessible medium may be embodied in an article of manufacture. Themachine accessible medium may include data that, when accessed by amachine, cause the machine to perform the operations described herein.The machine accessible medium may also include program code embeddedtherein. The program code may include machine readable code to performthe operations described in the following. The term “data” here refersto any type of information that is encoded for machine-readablepurposes. Therefore, it may include program, code, data, file, etc.

All or part of an embodiment of the invention may be implemented byhardware, software, or firmware, or any combination thereof. Thehardware, software, or firmware element may have several modules coupledto one another. A hardware module is coupled to another module bymechanical, electrical, optical, electromagnetic or any physicalconnections. A software module is coupled to another module by afunction, procedure, method, subprogram, or subroutine call, a jump, alink, a parameter, variable, and argument passing, a function return,etc. A software module is coupled to another module to receivevariables, parameters, arguments, pointers, etc. and/or to generate orpass results, updated variables, pointers, etc. A firmware module iscoupled to another module by any combination of hardware and softwarecoupling methods above. A hardware, software, or firmware module may becoupled to any one of another hardware, software, or firmware module. Amodule may also be a software driver or interface to interact with theoperating system running on the platform. A module may also be ahardware driver to configure, set up, initialize, send and receive datato and from a hardware device. An apparatus may include any combinationof hardware, software, and firmware modules.

While the invention has been described in terms of several embodiments,those of ordinary skill in the art will recognize that the invention isnot limited to the embodiments described, but can be practiced withmodification and alteration within the spirit and scope of the appendedclaims. The description is thus to be regarded as illustrative insteadof limiting.

1. A method for enabling an emulator that emulates an e-mode program toutilize stored data items whose values are stored in native data formatin native memory, the method comprising the emulator operations of: (a)fetching an item referenced by the e-mode program, the referenced itemcomprising a tag field and a data field; (b) determining whether the tagfield of the referenced item indicates that the referenced item is anexternal reference word (ERW); and (c) if the tag field of thereferenced item indicates that the referenced item is an ERW, decodingthe ERW to obtain a data type and a pointer, the pointer correspondingto a location of a stored data item in native memory.
 2. The method ofclaim 1 wherein the operations are performed by a ValueCall (VALC)operator of the emulator and operation (c) further comprises: creatingan object reference in native format in accordance with the obtaineddata type and pointer; fetching value of the stored data item fromnative memory using the created object reference; reformatting thefetched data item value to e-mode data format; and placing thereformatted data item value on top of a stack to provide the reformattedvalue to the e-mode program.
 3. The method of claim 1 wherein theoperations are performed by a StoreDelete (STOD) operator of theemulator and operation (c) further comprises: creating an objectreference in native format in accordance with the obtained data type andpointer; reformatting to native data format value of a data item to bestored; and storing the reformatted data item value in native memoryusing the created object reference.
 4. The method of claim 1 wherein theoperations are performed by a ValueCall (VALC) operator of the emulator,the method further comprising: (d) if the tag field of the referenceditem does not indicate that the referenced item is an ERW, determiningwhether the tag field indicates an indirect reference word; if the tagfield indicates an indirect reference word, fetching an item referencedby the indirect reference word; if the tag field does not indicate anindirect reference word, placing the referenced item on top of a stack.5. The method of claim 1 wherein the operations are performed by aStoreDelete (STOD) operator of the emulator, the method furthercomprising: (d) if the tag field of the referenced item does notindicate an ERW, determining whether the tag field indicates an indirectreference word; and if the tag field indicates an indirect referenceword, fetching an item referenced by the indirect reference word; if thetag field does not indicate an indirect reference word, storing thereferenced item in an e-mode memory.
 6. The method of claim 1 whereinthe tag field comprises more than four bits.
 7. The method of claim 1wherein the emulator constructs the ERW and puts the ERW on a stack as aparameter for the e-mode program at a point in time where the emulatordetermines that the e-mode program is going to be called by a nativeDynamic Link Library with the corresponding stored data item as aparameter.
 8. An article of manufacture comprising: a machine accessiblemedium including data that, when accessed by a computer, causes thecomputer to perform operations of an emulator for enabling the emulatorthat emulates an e-mode program to utilize stored data items whosevalues are stored in native data format in native memory, the operationscomprising: (a) fetching an item referenced by the e-mode program, thereferenced item comprising a tag field and a data field; (b) determiningwhether the tag field of the referenced item indicates that thereferenced item is an external reference word (ERW); and (c) if the tagfield of the referenced item indicates that the referenced item is anERW, decoding the ERW to obtain a data type and a pointer, the pointercorresponding to a location of a stored data item in native memory. 9.The article of manufacture of claim 8 wherein the operations performedby the computer are for a ValueCall (VALC) operator of the emulator andwherein the data causing the computer to perform the operation (c)further comprises data that, when accessed by the computer, causes thecomputer to perform operations comprising: creating an object referencein native format in accordance with the obtained data type and pointer;fetching value of the stored data item from native memory using thecreated object reference; reformatting the fetched data item value toe-mode data format; and placing the reformatted data item value on topof a stack to provide the reformatted value to the e-mode program. 10.The article of manufacture of claim 8 wherein the operations performedby the computer are for a StoreDelete (STOD) operator of the emulatorand wherein the data causing the computer to perform the operation (c)further comprises data that, when accessed by the computer, causes thecomputer to perform operations comprising: creating an object referencein native format in accordance with the obtained data type and pointer;reformatting to native data format value of a data item to be stored;and storing the reformatted data item value in native memory using thecreated object reference.
 11. The article of manufacture of claim 8wherein the operations performed by the computer are for a ValueCall(VALC) operator of the emulator and wherein the data further causes thecomputer to perform operations comprising: (d) if the tag field of thereferenced item does not indicate that the referenced item is an ERW,determining whether the tag field indicates an indirect reference word;if the tag field indicates an indirect reference word, fetching an itemreferenced by the indirect reference word; if the tag field does notindicate an indirect reference word, placing the referenced item on topof a stack.
 12. The article of manufacture of claim 8 wherein theoperations performed by the computer are for a StoreDelete (STOD)operator of the emulator and wherein the data further causes thecomputer to perform operations comprising: (d) if the tag field of thereferenced item does not indicate an ERW, determining whether the tagfield indicates an indirect reference word; and if the tag fieldindicates an indirect reference word, fetching an item referenced by theindirect reference word; if the tag field does not indicate an indirectreference word, storing the referenced item in an e-mode memory.
 13. Thearticle of manufacture of claim 8 wherein the tag field of thereferenced item comprises more than four bits.
 14. The article ofmanufacture of claim 8 wherein the data, when accessed by the computer,causes the computer to construct the ERW and put the ERW on a stack as aparameter for the e-mode program at a point in time where the computerperforming operations for the emulator determines that the e-modeprogram is going to be called as a by a native Dynamic Link Library withthe corresponding stored data item as a parameter.
 15. A system forenabling an emulator that emulates an e-mode program to utilize storeddata items whose values are stored in native data format in nativememory, the system comprising: a processor; a system memory coupled tothe processor, the system memory containing program code that, whenexecuted by the processor, causes the processor to perform operationscomprising: (a) fetching an item referenced by the e-mode program, thereferenced item comprising a tag field and a data field; (b) determiningwhether the tag field of the referenced item indicates that thereferenced item is an external reference word (ERW); and (c) if the tagfield of the referenced item indicates that the referenced item is anERW, decoding the ERW to obtain a data type and a pointer, the pointercorresponding to a location of a stored data item in native memory. 16.The system of claim 15 wherein the operations performed by the processorare for a ValueCall (VALC) operator of the emulator and wherein theprogram code causing the processor to perform the operation (c) furthercomprises program code that, when executed by the processor, causes theprocessor to perform operations comprising: creating an object referencein native format in accordance with the obtained data type and pointer;fetching value of the stored data item from native memory using thecreated object reference; reformatting the fetched data item value toe-mode data format; and placing the reformatted data item value on topof a stack to provide the reformatted value to the e-mode program. 17.The system of claim 15 wherein the operations performed by the processorare for a StoreDelete (STOD) operator of the emulator and wherein theprogram code causing the processor to perform the operation (c) furthercomprises program code that, when executed by the processor, causes theprocessor to perform operations comprising: creating an object referencein native format in accordance with the obtained data type and pointer;reformatting to native data format value of a data item to be stored;and storing the reformatted data item value in native memory included inthe system memory using the created object reference.
 18. The system ofclaim 15 wherein the operations performed by the processor are for aValueCall (VALC) operator of the emulator and wherein the program codefurther causes the processor to perform operations comprising: (d) ifthe tag field of the referenced item does not indicate that thereferenced item is an ERW, determining whether the tag field indicatesan indirect reference word; if the tag field indicates an indirectreference word, fetching an item referenced by the indirect referenceword; if the tag field does not indicate an indirect reference word,placing the referenced item on top of a stack.
 19. The system of claim15 wherein the operations performed by the processor are for aStoreDelete (STOD) operator of the emulator and wherein the program codefurther causes the processor to perform operations comprising: (d) ifthe tag field of the referenced item does not indicate an ERW,determining whether the tag field indicates an indirect reference word;and if the tag field indicates an indirect reference word, fetching anitem referenced by the indirect reference word; if the tag field doesnot indicate an indirect reference word, storing the referenced item inan e-mode memory included in the system memory.
 20. The system of claim15 wherein the tag field of the referenced item comprises more than fourbits.
 21. The system of claim 15 wherein the program code, when executedby the processor, causes the processor to construct the ERW and put theERW on a stack as a parameter for the e-mode program at a point in timewhere the processor performing operations for the emulator determinesthat the e-mode program is going to be called as a by a native DynamicLink Library with the corresponding stored data item as a parameter.